the administrator
the trusted computing base
the local security authority
the registry

via security policy
to individal users or groups
in order to control how the system behaves for various users
all of the above

True.
False. Services don't have tokens, they have Kerberos tickets.
Kerberos tickets are sent from clients to servers, and the server turns the ticket into a token for that client. But that's aside from the point that the server process itself has its own identity represented by a token, even if no clients are present.

expose the contents of a token via the IIdentity and IPrincipal interfaces
can often be found by looking in Thread.CurrentPrincipal if Kerberos is in use
can be used to peer at your own process token
all of the above

is a convenient way to keep track of the client identity for a given request
affects the way the operating system does access checks against files and other resources with ACLs
is typically cleared by an application programmer at the end of each method call
Plumbing like ASP.NET normally sets this up before calling into application code, so an application developer would not normally change this property; rather she would normally just read it. Also, this is NOT the same as impersonation, which we'll learn more about later. Impersonation is what causes the operating system to behave differently when it checks ACLs.

the interactive window station is terminated
the user's Kerberos tickets are returned to the domain controller for safekeeping
all programs in the corresponding logon session are shut down
The interactive window station never closes (unless the machine is rebooting), and the cached Kerb tickets are simply discarded.

are only used with Terminal Server
provide a sandbox for windowing components, which are not individually secured
are where Windows XP clients go to get authenticated upgrades and patches